Add admin-gated Release workflow - #610
Open
MaddyMicrosoft wants to merge 8 commits into
Open
Conversation
Reproduces the Azure Login Action release runbook as a manually dispatched workflow: checkout master, build, test, commit the built lib/ to a releases/vX.Y.Z branch, tag that commit, force-move the major tag (e.g. v3), and publish a GitHub Release. Admin-only is enforced two ways: - environment: release, which pauses the run until a required reviewer (admin) approves. This is the primary gate and must be configured with required reviewers in repo settings before the first real release. - an 'Ensure triggered by an admin' step that fails fast for non-admins. Actions are pinned to @v6 to match the rest of the repo.
Undo a bad release by re-pointing the major tag (e.g. v3) back to a known-good, already-published version tag. This is the fast consumer-facing fix: anyone on azure/login@v3 recovers immediately. - Admin-gated the same two ways as release.yml: environment: release approval plus an actor-admin check. - Shares the 'release' concurrency group so a rollback can never race an in-flight release (both push the same major tag). - Verifies the target tag exists and carries both built entry points (lib/main/index.js and lib/cleanup/index.js) before moving the major tag, so it can never point consumers at unbuilt code. - Optionally resets the 'Latest' release badge; tolerates a missing Release object so a cosmetic badge failure never fails a successful tag rollback. - Does NOT delete the bad tag/branch/release (someone may have pinned the exact version); left as a deliberate manual step. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 03:09 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 03:09 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 03:09 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 03:09 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 03:09 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 03:09 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 03:09 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 03:09 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 03:09 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 03:09 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 03:09 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 05:37 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 05:37 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 05:37 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 05:37 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 05:37 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 05:37 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 05:37 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 05:37 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 05:37 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 05:37 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 17, 2026 05:37 — with
GitHub Actions
Waiting
MaddyMicrosoft
had a problem deploying
to
Automation test
August 17, 2026 05:38 — with
GitHub Actions
Error
MaddyMicrosoft
had a problem deploying
to
Automation test
August 17, 2026 05:38 — with
GitHub Actions
Error
MaddyMicrosoft
had a problem deploying
to
Automation test
August 17, 2026 05:38 — with
GitHub Actions
Error
MaddyMicrosoft
had a problem deploying
to
Automation test
August 17, 2026 05:38 — with
GitHub Actions
Error
MaddyMicrosoft
had a problem deploying
to
Automation test
August 17, 2026 05:38 — with
GitHub Actions
Error
MaddyMicrosoft
had a problem deploying
to
Automation test
August 17, 2026 05:38 — with
GitHub Actions
Error
MaddyMicrosoft
had a problem deploying
to
Automation test
August 17, 2026 05:38 — with
GitHub Actions
Error
MaddyMicrosoft
had a problem deploying
to
Automation test
August 17, 2026 05:38 — with
GitHub Actions
Error
MaddyMicrosoft
had a problem deploying
to
Automation test
August 17, 2026 05:38 — with
GitHub Actions
Error
MaddyMicrosoft
had a problem deploying
to
Automation test
August 17, 2026 05:38 — with
GitHub Actions
Error
MaddyMicrosoft
had a problem deploying
to
Automation test
August 17, 2026 05:38 — with
GitHub Actions
Error
MaddyMicrosoft
marked this pull request as ready for review
August 18, 2026 01:50
The allowlist previously accepted releases/v2 for v2 maintenance, but releases/v2 is a stale early-v2 snapshot that does not contain the later v2 releases (v2.3.0, v2.3.1, ...). Releasing from it would ship old code. The latest v2 source lives in the newest v2 release tag. To cut a back-major release, branch a hotfix off that tag (git checkout -b hotfix/v2.3.2 v2.3.1), apply the fix, and release from the hotfix/* branch. Drop releases/v2 from the allowlist so it can no longer be selected by mistake. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
MaddyMicrosoft
requested a deployment
to
Automation test
August 18, 2026 02:48 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 18, 2026 02:48 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 18, 2026 02:48 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 18, 2026 02:48 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 18, 2026 02:48 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 18, 2026 02:48 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 18, 2026 02:48 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 18, 2026 02:48 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 18, 2026 02:48 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 18, 2026 02:48 — with
GitHub Actions
Waiting
MaddyMicrosoft
requested a deployment
to
Automation test
August 18, 2026 02:48 — with
GitHub Actions
Waiting
gh release create defaults to marking the highest-version release as "Latest", so a back-major release (e.g. a v2 hotfix) never steals the badge from the current major on its own. The explicit latest controls were therefore redundant, and rollback's badge edit conflicted with immutable releases. - release.yml: remove the latest input, the back-major latest guard, and the --latest flag on gh release create. - rollback.yml: remove the set_latest input and the gh release edit --latest badge step. Rollback now does only the major-tag move (matching the original runbook) plus the admin gate and built-artifact checks. The "Latest" badge is display-only and never affects what azure/login@vN resolves to, so this is behaviourally safe. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds two admin-gated, manually-dispatched workflows that automate the Azure Login release runbook:
release.yml(cut a release) androllback.yml(undo a bad one).Release workflow
Reproduces the release process end to end from a single dispatch:
lib/to a newreleases/<version>branch, tag<version>on that commit, force-move the major tag (e.g.v3), and publish a GitHub Release.action.yml, so each major builds with its intended toolchain (v2 → node20, v3 → node24).refinput (defaultmaster) supports back-major releases: branch a hotfix off the latest release tag (git checkout -b hotfix/v2.3.2 v2.3.1) and release from it. Allowlisted tomasterorhotfix/*only.latesthandling:gh release createlets GitHub auto-mark the highest-version release as "Latest", so a v2 hotfix never steals the badge from v3.Rollback workflow
Re-points the major tag back to a known-good, already-published version (the fast consumer-facing fix), mirroring the manual runbook:
lib/main/index.jsandlib/cleanup/index.js) before moving the major tag, so it can never point consumers at unbuilt code.Admin gating (both workflows)
Enforced two ways:
environment: release, which pauses the run until a required reviewer (admin) approves. This must be configured with required reviewers before first use.Both share a
releaseconcurrency group so a release and a rollback can never race on the same major tag. Actions are pinned to@v6, matching the rest of the repo.Notes
vX.Y.Z), ref allowlist, and version-is-new (tag/branch must not already exist).releaseenvironment to exist with required reviewers; the workflows are inert-but-safe until it is configured.